\pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\fc0 is not preemptable at this point. This topic is a source of continuing work
\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc0 at NeXT,
\pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\fc0 so that we may achieve some guaranteed
\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc0 r
The primary support in 2.0 for real-time programming is the addition of scheduling policies that can be set on a per-thread basis. We currently have three scheduling policies: POLICY_TIMESHARE for traditional UNIX scheduling, POLICY_INTERACTIVE designed for interactive behavior for applications, and POLICY_FIXEDPRI for non-degrading realtime priorities. Additionally, thread_switch() can be used to do user-level scheduling among a set of threads.\
\
The DSP is inherently a real-time programming environment. It is best used for low-level interrupt processing and data reduction/expansion. It's currently used this way for real-time expansion of sound before it's played, as well as data reduction of input from the DSP serial port. The DSP can then communicate with a Mach task using the Sound/DSP driver interface. The combination of these features makes the NeXT a suitable platform for a wide range of real-time programming tasks. The key is to require no more than 100ms responsiveness from Mach-level programs with a light virtual memory load.\
\
In the future we hope to remove the remaining barriers to Mach-level real-time programming by enhancing the scheduler behavior and supporting user-level wiring of virtual memory resources.\
